Codecov Report

Merging #566 into develop will increase coverage by 0.17%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #566      +/-   ##
===========================================
+ Coverage    36.94%   37.11%   +0.17%     
===========================================
  Files           21       21              
  Lines         2891     2891              
===========================================
+ Hits          1068     1073       +5     
+ Misses        1728     1724       -4     
+ Partials        95       94       -1

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 00ded41...8c21479. Read the comment docs.

My knowledge about Go modules is pretty much zero, but is there a way we could separate the versioning of the Go codebase from the versioning of the sops binary, which is effectively the only thing we actually version with semver? If we do that, could we call this 'v1' of the codebase and not have it in the import path? Or do you have the have the 'v1' there anyway?

My knowledge about Go modules is pretty much zero, but is there a way we could separate the versioning of the Go codebase from the versioning of the sops binary, which is effectively the only thing we actually version with semver? If we do that, could we call this 'v1' of the codebase and not have it in the import path? Or do you have the have the 'v1' there anyway?

The thing I'm not really sure on is how changing the go.mod at the root of the repo exactly impacts the sops binary. Using go 1.13, go get -u go.mozilla.org/sops/cmd/sops works exactly as you'd expect it to right now. I'm curious if with this change we would actually need to update it to go get -u go.mozilla.org/sops/v3/cmd/sops or whether go get -u go.mozilla.org/sops/cmd/sops would continue to work as expected.

Additionally, forgot about #540, will want to include that in this PR.

I see. I have to think about this a bit more, I'll try to do that over the weekend, but feel free to merge to develop for now.

Basically, I think there's two things we need to version here:

1. go.mozilla.org/sops/cmd/sops
2. go.mozilla.org/sops/decrypt

And everything else should be unversioned if we can get away with it. As I said, I'll look and see if this is actually possible. A quick read of go modules makes me think it's not. Perhaps if they were on different repos.

@autrilla From what I can tell from my experiments it seems like this might cause only minor breakage for some users.

One concern that I had was whether this could require all users using the sops/decrypt module within their codebases to start using go modules. This does not seem to be the case, surprisingly:

root@18591ccbf56d:/go/t# go version
go version go1.9.7 linux/amd64

root@18591ccbf56d:/go/t# cat ../src/github.com/ajvb/modules-testing-sops/go.mod              
module github.com/ajvb/modules-testing-sops/v2

go 1.13

root@18591ccbf56d:/go/t# cat ../src/github.com/ajvb/modules-testing-sops/anotherfile.go 
package modules_testing_sops

import "fmt"

func AnotherExampleFunc(msg, secondMsg string) {
        fmt.Println(msg)
        fmt.Println(secondMsg)
}

root@18591ccbf56d:/go/t# cat ../src/github.com/ajvb/modules-testing-sops/submodule/example.go 
package submodule

import "github.com/ajvb/modules-testing-sops/v2"

func SubmoduleFunc(msg string) {
        modules_testing_sops.AnotherExampleFunc(msg, msg)
}

root@18591ccbf56d:/go/t# cat main.go 
package main

import "github.com/ajvb/modules-testing-sops/submodule"

func main() {
submodule.SubmoduleFunc("test")
}

root@18591ccbf56d:/go/t# go run main.go 
test
test

Though the above is seemingly using code with import "github.com/ajvb/modules-testing-sops/v2" and is running on go 1.9, it seems to work as expected without having the specify the v2 itself.

As well, go get to run the binary (or more explicitly, outside the context of a go module) cannot make use of versions, so you should be able to still run go get -u go.mozilla.org/sops/cmd/sops and get master.

I think where this might cause stuff to break is that people who have sops with a commit pin in their go.mod like go.mozilla.org/sops v0.0.0-20190611200209-e9e1e87723c8 and want to use it with go 1.13 will need to change it to go.mozilla.org/sops/v3 v3.4.1 or similar.

Please feel free to double check me as I still feel very new to go modules, but I think we are in the relative clear for breakage.

Lastly, after thinking about it a bit, I think that versioning the decrypt module and the sops binary separately would be a major change in how we structure the sops project and I don't quite see the value as long as we can reduce the breakage for our users. Keeping the binary and modules in sync version wise allows for very clear expectations on what versions of the binary or various modules will work with each other. Having a case where versions 1.X of the decrypt module work with 3.X through 4.4 of the binary or something could create a lot of confusion, both for us and for our users.

@ajvb thanks a lot for explaining. I am very surprised things still work for older versions of Go, so since that's the case, I have no objections to merging this whatsoever!

@autrilla Of course! Same hehe and sounds good.